The present invention relates generally to financial transactions, particularly to customers requesting financial transactions with merchants, and more particularly to financial transactions conducted with a financial institution portable payment device issued by a financial institution, such as a credit card that, that may be used both in a retail transaction and in a transit fare transaction.
Portable payment devices can take many forms and are used in a great variety of financial transactions. The portable payment devices can comprise, for example, smart cards, payment tokens, credit cards, debit cards, stored value cards, pre-paid cards contactless cards, cellular telephones, Personal Digital Assistant (PDA) devices, key fobs, or smart cards. The financial transactions can involve, for example, retail purchases, transit fares, access to venue fares, etc. In all such transactions, the portable payment device users (consumers) are concerned with convenience and the merchants with whom they deal are concerned with ease of transacting with their customer-consumers.
Preferably, financial institution portable payment devices issued by a financial institution (FIPPD) are used in an on-line fashion (e.g., a point of service that is connected to a payment processing system during a transaction). The information from the FIPPD may be transmitted on-line to an issuer during a retail payment transaction for purposes of authorizing the use of the FIPPD for that transaction. The issuer may review parameters of the transaction such as transaction amount, credit history, card authenticity, and other factors when determining whether or not to authorize or decline the transaction.
However, some merchant transactions are not on-line such that FIPPD authentication and verification schemes are not readily accommodated. For example, the ability to go on-line in a transit environment such as a subway or bus system, or a venue access environment such as a stadium or concert hall, may be problematic because of the lack of real time communication and lack of network systems for such environments. This is due in part to the need in such environments to process a transaction within about 300 ms, a transit system industry standard, and thereby allow 30 to 45 patrons per minute access into a facility of the transit system such as a subway or a bus. Moreover, a bus on an over-the-road bus route may not have wireless or other communication systems to allow any real-time dialogue with any other systems outside of the bus, such as for on-line fare assessment or on-line admission ticket/voucher/card authorization. Therefore this absence of network connectivity in a transit environment presents a difficulty whenever an on-line authentication of the consumer's means of access, such as an admission ticket, voucher, or access card, is necessary in order to determine whether, for instance, the consumer is entitled to access and has sufficient funds to cover the cost of the desired transaction (fare for riding on the transit system).
Moreover, in a transit environment, the value of the transit fare may not be known at the time of requested access. A fare calculation may depend upon the actual travel distance, direction of travel, station entry and exit locations, mode of travel (subway, bus, water taxi), consumer category (student, senior), and/or times of use (peak, off-peak). Such parameters may be unknown prior to rendering the service. As such, the transit fare payment and collection process cannot be performed effectively using a conventional on-line authentication and approval process.
Traditionally, transit fare calculation and collection have occurred in a closed system. In a closed system, the transit company may issue its own transit portable payment device, such as a read/write smart card, wherein the transit portable payment device carries the necessary credentials and data to allow completion of a transaction at the fare device itself (turnstile, fare box, or other Point of Service). In this case, there is no additional processing required for fare determination at the time of the transaction outside of the interaction between the card and the fare device. Rather, the card is authenticated and read by the fare device, logic is performed by the fare device to apply transit system fare policy, and the card is updated (rewritten) to finalize the transaction details including a deduction of any stored value for the cost of fare. The fare device may additionally query a white list, a positive list, a hot list, a negative list and/or a black list utilizing the card number, for example, to determine whether the transaction will be completed and the cardholder will be allowed access into a facility of the transit system such as a subway terminal or bus passenger compartment.
The closed transit system, however, has its drawbacks. In a closed transit system, the transit portable payment device and transit readers at each station or route must be able to perform fare computations based on data stored and retrieved from a rider's access card, and subsequent card terminals/readers must be able to access data written to the rider's access card at previous stations. This requirement places a significant processing burden on the transit system terminals and/or fare processing systems and increases the cost of implementing the infrastructure for such systems. As fare rates and other relevant information generally change over time, this also increases the demands placed upon such systems for maintenance of accuracy.
Moreover, one transit portable payment device may not be compatible with all of the fare devices within a rider's travel plan. This can become a significant problem if a consumer wishes to utilize more than one transit system during a day's commute, such as by using multiple transit agencies or venues within a single geographical area that provide ridership both in and among different jurisdictions, cities or locations.
The present transit environment presents several challenges, including:                A common necessity that there can be only one transit portable payment device for each transit agency or group of cooperating agencies that cannot be used for other such agencies or groups;        The desire to accommodate transit system user's transaction speed expectations while minimizing risk to the transit agency for collecting payment for services rendered; and        When a portable payment device is ‘read-only,’ not having write capabilities at the Point of Service, the PP devices cannot store the rider's transit chronology data—thus making the rider's fare calculations somewhat difficult with such devices. With such off-line transactions, a list (i.e., a white list of eligible cards or a negative list of rejected cards based on the unique card number) stored at each transit fare device is the primary mechanism to deter fraud. This is sub-optimal since the negative list would presumably grow unbounded as more FIPPD are issued.        
In addition to the transit system rider's desire for a fast transaction speed when accessing a transit system facility, there are security and other risks associated with the use of a FIPPD that is designed for on-line authorization when it is otherwise used in an off-line transaction. These risks include, but are not limited to:                Authentication/Fraud: the lack of FIPPD authentication in real time creates a high potential for fraud through counterfeiting techniques;        Fare Cost Calculation: where the cost of a transit transaction is dependent upon the immediate rider history for the card (entry/exit/length of travel, transfers, etc.), the rider's transit fare cannot be calculated at each gate or fare box because the rider's immediate history of travel cannot be stored, written or resident on conventional FIPPDs;        Data Security/Storage: protection of consumer data in a transit fare system may prove difficult. Tracking data in the form of a primary account number (PAN) for a FIPPD would require the transit system to collect and store this data securely, which is not something transit fare systems commonly do presently. If implemented, this requirement presents added cost and security concerns to both the transit system and its riders; and        
Payment cards are generally required to go on-line to the issuer during the transaction for purposes of authorizing the use of the card for that transaction. The issuer may review such parameters as transaction amount, credit history, card authenticity, and other factors when determining whether or not to authorize the transaction.
In some payment applications the opportunity to go on-line to the issuer for authorization may not be possible at the time of the transaction. This may be due to transaction speed requirements, and/or connectivity requirements at the payment device. For example, a transit fare device such as a subway turn style or bus fare box must complete a transaction within less than 300 milliseconds to allow time to process 30 to 45 passengers per minute as required in that application. In another example, a transit bus or a taxicab may be on the road without real-time communications with the issuer for authorization. In these cases, the merchant (transit agency, taxicab driver, etc) must allow the transaction to take place without authorization and then process the transaction at a later time after the cardholder is allowed to proceed.
Because the cardholder is allowed to proceed in advance of receiving authorization from the issuer, there is opportunity for fraud. The issuer is not allowed the opportunity to authenticate the card or authorize based on other parameters of the transaction, a fraudster with a counterfeit card would be allowed to proceed with the transaction without any checks and balances.
One mechanism widely used to curb counterfeit fraud in off-line applications is through the implementation of a negative list (sometimes referred to as black list or hot list). Each off-line payment processing device (such as a bus fare box) is provided, on a regular basis, with a list of card numbers thought to be counterfeit (or fraudulent for other reasons). During the processing of the transaction, the payment device may check the card number against the negative list and allow or deny the transaction based on this check and balance.
Although negative list checks provide a mechanism for curbing fraud in off-line applications, the negative list itself opens the door to other types of fraud opportunity based on the potential exposure of the card numbers on the negative list. In the case of a payment card being used to pay for transit fares, taxi fares, or vending machine goods, a negative list would necessarily be made of payment card account numbers (i.e. Primary Account Numbers, or PANs). The PAN is the only number provided by the card during the payment transaction and therefore would be the number placed on the negative list to deny its use. If the negative lists were exposed or compromised, the opportunity for large lists of payment card account numbers would be possible.
Different payment processors can maintain different cardholder information security and protection programs as well as requires merchant systems that process cardholder information, such as payment card numbers (PAN's), to be compliant with these programs. These security and protection programs can provide protection by requiring that cardholder information that must be stored, be done within one or more different encrypted formats. This includes off-line transit fare devices, taxicabs, or vending machines that would have to store PAN numbers in the form of negative lists. However, not all merchants have encryption systems or processes imposed stringently to protect cardholder data as required. Furthermore, encryption techniques may not be secure enough for unattended devices found in remote locations that may be vulnerable to physical attack, hacking, and exposure of payment account information.
Given the foregoing, it would be an advance in the art to protect cardholder information, stored in negative lists in off-line applications. It would further be an advance in the art to provide such protection in any off-line environment such as transit fare collection, taxi cabs fare payment, vending machines payments, venue access, parking meters or machines, or other applications that may not have connectivity or time permitted to go on-line to the issuer for payment authorization—including where the environment permits smart or ‘chip’ cards, whether the card or other payment device is a contact or contactless wireless (e.g.; Radio Frequency) card as are typically found in the transit environment.
What is still further needed in the art is the payment and collection of transactions utilizing a FIDDP device within the above environments, including access fares to transit systems and venues, that overcome the challenges and disadvantages of the prior art as set forth above.